Introducing Progress Dynamics
The Progress Dynamics® framework is a comprehensive, repository-based environment for OpenEdge® Studio developers who are building new applications, or who need to migrate existing applications to take advantage of new OpenEdge technologies. A Progress Dynamics application is built up of many components of different types. Some of these provide support for the user interface, such as windows, browsers, viewers, toolbars, and tab folders. Others are procedural objects that define the business logic of an application. Many application components are dynamic or data-driven objects, created at run time using data in the Dynamics Repository. Progress Dynamics is to some extent based on the OpenEdge Application Development Model (ADM) and OpenEdge SmartObjects™, which provide a basis for defining and combining standard components. Progress Dynamics extends the ADM and adds even more capabilities to the OpenEdge development environment.
The Progress Dynamics Repository stores data for a wide variety of purposes. Most application objects are represented as data stored in the Repository, so you do not need to create, compile, deploy, or maintain the source code for them. The framework includes programs that render these objects at run time from the data in the Repository.
Progress Dynamics is designed to run in a distributed, n-tier environment, with the visual portion of the application running in either a 4GL client session or some other client type, without a local database connection. Business logic runs on one or many AppServers™ for OpenEdge applications where you can locate the repository database and the application database, maximizing efficiency of access to the database.
Progress Dynamics access to the AppServer is always stateless, so that a small pool of AppServer sessions can support a large number of clients.
To support this stateless AppServer access, Dynamics includes a number of Environment Managers to handle various aspects of the application and its environment. Each of these procedures runs as both a client-side process and a server-side process. The server-side manager maintains one or more repository database tables on the server and provides data to client sessions as needed. Data is cached on the client for maximum efficiency and returned to the server when necessary to allow the repository database to provide persistent storage for all data related to the running of the application.
Figure 1–1 shows a diagram of the Progress Dynamics run-time architecture and how the different components are related.
This chapter describes the following components that make up Progress Dynamics:
Progress Dynamics combines these elements with a best practices approach that allows you to take full advantage of the framework’s capabilities. The best practice recommendations lead you without being unnecessarily restrictive. This approach provides guidelines for:
For an existing application that you migrate to the Progress Dynamics framework, these best practices provide the design and implementation guidelines against which you can assess how to prepare your application for migration. The more compliant an existing application is with Progress Dynamics guidelines, the easier it is to migrate. In keeping with the flexible scope of Progress Dynamics, you can still migrate an existing application using a subset of these guidelines.
In particular, the separation of business logic from the UI logic is essential to provide your application with the maximum deployment flexibility. Some OpenEdge deployment models (for example, OpenEdge WebClient™) do not work at all without this separation of your application logic. Progress Dynamics provides additional support to help you distribute your application logic appropriately.